1. Field of the Invention
The present invention relates generally to information processing environments and, more particularly, to a database system providing methodology for extended memory support.
2. Description of the Background Art
Computers are very powerful tools for storing and providing access to vast amounts of information. Computer databases are a common mechanism for storing information on computer systems while providing easy access to users. A typical database is an organized collection of related information stored as “records” having “fields” of information. As an example, a database of employees may have a record for each employee where each record contains fields designating specifics about the employee, such as name, home address, salary, and the like.
Between the actual physical database itself (i.e., the data actually stored on a storage device) and the users of the system, a database management system or DBMS is typically provided as a software cushion or layer. In essence, the DBMS shields the database user from knowing or even caring about the underlying hardware-level details. Typically, all requests from users for access to the data are processed by the DBMS. For example, information may be added or removed from data files, information retrieved from or updated in such files, and so forth, all without user knowledge of the underlying system implementation. In this manner, the DBMS provides users with a conceptual view of the database that is removed from the hardware level. The general construction and operation of database management systems is well known in the art. See e.g., Date, C., “An Introduction to Database Systems, Seventh Edition”, Addison Wesley, 2000, the disclosure of which is hereby incorporated by reference.
Database systems are well known and in wide use in a wide range of applications running on a variety of different hardware and operating system platforms. However, the use of database systems on certain platforms is hindered by the limited addressable memory that is available on these platforms. For example, one platform that is in use today is the Linux operating system running on a hardware platform that utilizes 32-bit processors (e.g., Intel 32-bit processors). Using this Linux 32-bit platform can provide a cost effective solution for enterprise level information technology requirements as it can be a less expensive solution than 64-bit architectures. However, applications running on this platform currently have a limitation of only being able to use less than 4 GB (addressable range) of memory on 32-bit architectures. Standard 32-bit addresses can map a maximum of 4 GB of memory. By default, a portion of this memory (e.g., 1 GB or 2 GB) is typically reserved for the operating system, and therefore in practice less than 4 GB is available to an application running on a 32-bit platform. Given that most database server installations are larger than 4 GB, a mechanism for overcoming the memory limitations of these 32-bit platforms is needed in order to facilitate the use of database applications on these platforms.
One current technology that can be used to address this limitation is an Intel “Physical Address Extension” (PAE) technology which allows more RAM to be used with certain 32-bit systems. Generally, PAE makes 4 extra bits available for the addressing of memory, thereby allowing up to 64 GB of memory to be addressed. With PAE, a system (e.g., an Intel Xeon-based system) can house up to 64 GB of memory on 32-bit platforms as 16 segments of 4 GB per segment. Briefly, PAE is a memory management function that provides more physical memory to a program (e.g., application program) that requests memory. The program (e.g., application) is usually not aware that any of the memory that it uses resides in the range greater than 4 GB. With PAE enabled, the operating system essentially moves from a two-level linear address translation to a three-level address translation. The extra layer of translation is what provides access to physical memory beyond 4 GB. Instead of a linear address being split into three separate fields for indexing into memory tables, it is usually split into four separate fields; a 2-bit field, two 9-bit fields, and a 12-bit field that corresponds to the page size implemented by the Intel architecture (4 KB).
During a context switch a register (e.g., a CR3 register) is set by the operating system to point to a page directory pointer index that is 2-bits wide. The first two bits are used as an index into this table, with the resulting value pointing to a page directory. The first 9-bit field is then used to index into the page directory. The indexed value then points to a page table. The second 9-bit field is an index into the page table. This value points to the actual page in memory where the desired byte is located. Finding this byte is a matter of using the remaining twelve bits of data to index into the page.
PAE allows a processor to address up to 64 GB in theory but, in practice, applications still may not be able to access that much memory without the use of other mechanisms. Currently, an application using the additional memory provided by PAE has to move from segment to segment and keep track of its position. The memory is not mapped by the operating system for the application, so that the application can simply open an address from 0 to 64 GB. Rather, the application itself must generally manage, on its own, the mapping to the extended memory.
Operating system (OS) vendors have provided some mechanisms and application programming interfaces (APIs) to allow applications to address more than 4 GB of memory (RAM) on 32-bit platforms using PAE. For example, on certain Microsoft Windows platforms (e.g., Windows 2000) an “Address Windowing Extensions” or “AWE” API is available to support larger amounts of physical memory. AWE is a set of extensions to the memory management functions of the Microsoft Win32 API that allow applications to address more memory than the 4 GB that is available through standard 32-bit addressing. AWE lets applications acquire physical memory as non-paged memory, and then dynamically map views of the non-paged memory to the 32-bit address space. Although the 32-bit address space is limited to 4 GB, the non-paged memory can be much larger. This process enables memory-intensive programs, such as large database systems, to reserve large amounts of physical memory for data without having to be paged in and out of a paging file for usage. Instead, the data is swapped in and out of the working set and reserved memory is in excess of the 4 GB range. Although the Address Windowing Extensions enable memory-intensive applications (e.g., large database systems) to address more memory than can be supported in a 32-bit address space, the AWE mechanism is available only certain Windows platforms and is currently not supported on other platforms (e.g., Linux platforms).
Although the above discussion refers to the addressable memory limitations of 32-bit platforms, this is only one example of a more general problem. Memory limitations may also be applicable and may impact the performance of database systems on various other platforms. Given any arbitrary physical memory constraint that may be applicable, what is needed is a solution that enables memory-intensive applications, such as large database systems, to utilize extended memory for overcoming these limitations. For example, one may wish to implement an application in an environment in which a portion of the memory for the application is provided on a first device and another portion of the memory is provided on a second device (e.g., a less expensive device such as a file server or the like). Consider, for instance, an environment including a cluster of machines. It is would be desirable to be able to provide extended memory on various machines in the cluster and have a mechanism that mapped to extended memory located anywhere in the cluster. What is needed is a system and methodology for mapping to extended memory on various devices so that an application can bring data in from various sources without needing to know or be concerned about the underlying location of this data.
In a typical database application, the memory that is required by the database system is mostly used for data caches. For example, all or portion of a table or index is loaded from disk into cache memory to facilitate access to such data and avoid expensive disk reads and writes which can also serve to increase latency. In a typical database server implementation, a major portion of memory utilization (e.g., on the order of 90 percent of memory utilization) relates to data caches, while a much smaller portion (e.g., the remaining 10 percent) relates to connection caches and other miscellaneous purposes. What is needed is a solution providing for caching data in memory which reduces the frequency of read and write operations from disk, thereby reducing the impact of these operations on system performance.
One approach that has been used in an attempt to overcome the memory limitations of certain platforms is to use operating system provided file systems or other such devices to provide extended memory to an application. However, in a transaction processing environment, a mechanism of this type (e.g., an operating system file system) does not support the transaction needs of a database server system. For one thing, using this type of mechanism makes it very difficult to optimize the execution of transactions. Also, this mechanism is not extensible and it usually forces one to choose one particular interface on a particular platform. A more flexible and extensible approach that can be plugged into various implementations in order to provide extended memory support to memory-intensive applications is desired.
What is needed is a solution which enables memory intensive applications, such as large database systems, to address more memory than can be supported in the address space of a given platform (e.g., a 32-bit platform). Ideally, the solution should provide extended memory support without requiring the application using the extended memory to be concerned about the details involved in mapping to or otherwise managing the extended memory. The present invention provides a solution for these and other needs.